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LOCAL COMMUNICATION SYSTEM 



A local communication system which combines source 
data (CD audio, MPEG video, telephone audio etc) with 
5 control commands in a low cost fibre network is available 
in the form of D2B Optical. For details, see for example 
the "Conan Technology Brochure" and the "Conan IC Data 
Sheet" available from Communication & Control Electronics 
Limited, Stirling House, Stirling Road, The Surrey 

10 Research Park, Guildford, Surrey GU2 5RF, An extract 
from the CONAN IC Data Sheet is attached hereto as an 
Appendix. See also German patent applications of Becker 
GmbH with filing numbers 19503206.3 (95P03), 19503207.1 
(9 5P0 4 ) , 19503209 .8 ( 95P0 5 ), 19503210.1 ( 9 5P0 6 ) , 

15 19503212.8 (95P07), 19503213.6 (95P08), 19503214.4 
(95P09) and 19503215.2 (95P10). "Conan" is a registered 
trade mark of Communication & Control Electronics 
Limited. 

20 The present invention aims to enable expansion of 

the capacity of such a network, for use in vehicles and 
the like, towards a capacity necessary for higher bit- 
rate multimedia applications such as MPEG2 audio, MPEG2 
video. Digital Audio Broadcasting (DAB), Digital 

25 Versatile Disk (DVD) and other data. 

One proposed embodiment employs asynchronous 
transfer mode data transport for the various data types, 
accommodating both high bit rate and low bit rate data 
30 channels. .However, the ATM packet is not limited to the 
conventional ATM packet of 5 bytes of header and 48 bytes 
of payload, but is adapted to provide more efficient use 
of bandwidth in the target applications. / 

35 Also, compared with D2B Optical (CONAN) technology. 
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it is proposed to use a more compact encoding technique 
for the fibre interface^, such as the 4B5B or 8B10B 
encoding,, currently used in FDDI (Fibre Distributed Data 
Interface) for metropolitan area networks (MANs). 

Embodiments are proposed, in which each network 
frame includes subframes of at least two different modes: 
"mode 0" subframes provide compatibility with the fixed 
bit-rate (e.g. circuit-switched) CONAN technology, while 
simultaneously the "mode 1" subframe provides a group of 
bytes which can be allocated more freely to implement a 
variable bit-rate (e.g. packet-switched) channel. In 
other embodiments, a common source data channel is 
allocated dynamically between circuit-switched and 
packet-switched data. 

These proposals and surrounding considerations are 
described in the following pages , together with some 
alternatives also proposed herein. 
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1. Introduction 

This document comprises an outline proposal for a high speed D2B which works v/ith 
an optical interface (Plastic Optical Fibre). The proposed device is known as the high 
speed D2B and is designated as C&C Electronics part number HSCI8001 . 

2. Objectives 

The objectives of the HSCI8001 development are as follows 

• To integrate many of the digital audio and video systems over a 
common data bus and come up with a suitable protocol that will be 
able to integrate them. 

• Baseline for the High Speed Conan 

• Use of Plastic Optical Fibre 

• Low cost LED Transceiver technology 

• Bandwidth requirements > 25 Mbs 

• Ring Topology for ease of installation, low cost Fibre Optics 
components and low power consumption... 

3.0 Requirement Constraints 

3.1 Topology 

• Point-to-point links 

• Linear T bus 

• Star system 

• Reflective star 

• Transmissive Star 

3.2 Line encoding 

There is a need for a more efficient encoding/decoding technique than 
what is currently used on the current Conan chip (BI-PFIASE). One type 



of encodip""/ '^<»/^/^--^T"t-•,-r t-or-u^: <.u„* • i . . 

ijT ° —-'"6 ^v-oiixxi4uc uiac is curreruiy used in FDDI which 

would be considered is the use of 4B5B encoding technique. This would 

provide the High speed network a reliable and efficient technique. 

• BI Phase encoding for current Coaaxi design 

• 4B5B/8BI0B 

3.1 Data rate Requirements 

• Parameters identified for the various digital audio video systems for 
mtegration over a conmon databus. The tabulated values indicate the some 
ot the ovemding parameters between systems.. 



Data Type 


Variable 

Bandwidth 

Requirements 


Common 
Frequency 


Frame Structure 


MPEG2 Audio 


up to 912kbps 


48kbps 




MPEG2- Video - 


-1.55 to 4Mbps- - 






DAB 


I -5Mbps? 


48kHz 


16-32 Bits 


DVD- 


n.OSNfbps 




2048bytes Packet 


CD 


1.44Mbps 


44.1kHz 


16-24Bits 


ATM (Use this as 
a Transport for 
above Data Types) 






Similar to Sbytes of 
Header and 48 
Bytes of Payload 



3.4 Topology 

The communications network forms a backbone of most architectural designs 
and hence the mterconnections can influence the final design. Network 
topology fall mainly into three categories. 

For the application that we are considering a Ring topology is still the 
prefenrcd option as it means that the components available for the Optical 
network wiU still be relatively cheap and low power, rather then going to a 
relatively expensive star network. 

These point are discussed further in the sections below. But it is hughly likely 
that if m a large network environment if the system could not handle the delay 



then a star network could be the way forward if the components become 
available for the Plastic Fibre optics and arc relatively cheap. 

Point-to-point links; 

Point to point dedicated links are used in two ways. Firstly by a dedicated link 
between each communicating function. Secondly by a dedicate link between 
terminals and using electronics in each terminal to strip off data which is 
addressed to that particular terminal and pass any ftirther data to other 
terminal. 




Linear T- Bus 
« 

These are relatively simple to implement if using voltage mode or current 
mode coupling and provide a broadcast medium that allows all terminals to 
simultaneously listen to the traffic on the network. This has been used in many 
of the electrical broadcast bus designs, but is far less popular for optical 
systems as dne excess loss at each Junction leads to extremely large link power 
budgets. 




Stars 

These can split light from a fibre into a number of other fibres in a reversible 
manner, that is l:n or n:L Many networks using fibre optics are implemented 
using a topology based on reflective and transmissive star couplers. But teh 
cost penalty is higher. 
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Detailed Proposal I 

The following pages present a first embodiment of 
a High Speed D2B netv/ork offering high speed variable bit 
rate channels ("Mode 1" data) simultaneously with fixed 
5 rate channels ("Mode 0") compatible with the known 
"CONAN" technology (and with the proposed "SuperCONAN" 
technology having an increased capacity of fixed data 
rate channels). 

A "MegaCONAN" chip is described, a key feature of 

10 which is the provision of dual processors. The first 
processor is a RISC processor corresponding to that used 
in the existing CONAN chip for implementing the D2B 
system with control of the fixed data rate ("Mode 0") 
data routing. The second processor, handing the 

15 asynchronous ("Mode 1") data is a digital signal 
processor (DSP) which can implement, for example sample 
rate conversion, audio DSP functions (such as Dolby ACS ) , 
and can interface to on-chip or off-chip for DVD and 
other data formats, 

20 
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Detailed Proposal II 

The following pages present a .modified embodiment, also 
providing both variable and fixed rate channels, but with 
5 flexible allocation of bytes within a common source data 
channel. Notable changes relative to Detailed Proposal 
I above are explained as follows: 

The delay at each network node in processing each 
10 frame of Proposal I would have been greater than 1 

sub-frame when using a network containing both D2B 
Optical and High Speed D2B network nodes. Since a 
conventional D2B Optical network can only handle a 
-maximum of 1 sub-frame delay around the network 
15 such a "mixed mode" network would not have 

functioned correctly. In the Proposal II the 
maximum delay is 12 High Speed D2B bits (= 3 D2B 
Optical bits) thus up to a theoretical limit of 20 
nodes (16 when accounting for typical processing 
20 delays through each node) can be placed in a mixed 

mode network. 

^ - In the Proposal I the allocation of circuit- 

switched synchronous traffic (Mode 0) and 

25 asynchronous packet based traffic (Mode 1) was 

fixed at 256 bits each. la Proposal II the traffic 
can be allocated in a flexible manner from 100% 
Mode 0 to 100% Mode 1 in increments of 1 source 
byte from 0 source bytes to 60 source bytes in a 

30 frame. Total source data capacity is now 23.04 

MBPS at Fs = 48 kHz (DVD sample rate). 

- The frame structure allows transmission of 1 
. complete- ATM cell (53 bytes equivalent to a bit 

'35 rate of 20.352 MBPS) in' 1 frame as Mode i traffic 



20 

with 7 bytes left for Mode 0 traffic (2.688 MBPS 
or, for example, 2 stereo digital CD channels). 
Thus the network can be - used to transparently 
connect nodes with ATM data interfaces, if desired- 

Compatability is maintained as before by using a 
common control channel structure as currently used 
in D2B Optical sytems (at a rate of 176.4 kbps at 
Fs 44.1 kHz) ("Conan" technology). 

When using a network in which all nodes are High 
Speed D2B Nodes additional control channel capacity 
can be added by using the 4 bits in the Right Pre- 
amble to increase the control channel capacity to 
352 .8 kbps at Fs =^44.1 kHz... 

Line coding efficiency is improved using 4B/5B line 
coding to reduce the overhead to just 20%. Thus 
the rate at which optical transceivers are required 
to be driven reduces to 29.4912 MHz (at Fs = 48 
kHz) as compared to 49.152 MHz for bi-phase 
encoding . 

Statistical multiplexing can be used to multiplex up to 
4 DVD channels onto the High Speed D2B Bus. This relates 
to calculating node buffer sizes in a distributed video 
transmission network. 
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Detailed Proposal III 



A further example v/ill now be presented, which differs 
from Detailed Proposal II in various ways. 

5 

The number of source data bytes per sub-frame is 
increased to 46, giving a continuously allocatable 92 
source data bytes per frame. The frame rate is fixed at 
48 kHz, giving a higher overall data rate than in 
10 Detailed Proposal II. 
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Detailed Proposal III also provides more detail of the 
control of asynchronous channel allocation, and a package 
structure for data within the asynchronous channels. 



Although the variable width (asynchronous) channels and 
the fixed rate (synchronous) channel's are again allocated 
within a single source data field from different ends, 
in this proposal the asynchronous traffic is allocated 

2 0 in the source bytes from the beginning of the frame, not 

the end. At the start of each block of 4 8 frames, 
asynchronous block headers are provided which indicate 
a channel ID and channel width which are fixed for the 
remainder of that block. The header for successive 
25 channels is found by counting through the source data 
bytes of the first frame in accordance with the width of 
each channel. The synchronous data channels are 
allocated from the end of the source data field. 

3 0 Packets carrying 42 bytes of source data in this example 

can also be grouped into packs of up to 256 packets. 
This can assist data handling in applications' where 
larger segments of data, such as disk segments of 2 
kbytes are expected. A DVD source, for example, normally 
35 provides data in so-called PES cells of 188 bytes, which 
could, if desired, be grouped as pack of 5 of the 
proposed asynchronous data packets. 

A detailed description of Proposal III now follows. 



System Description 

A High Speed D2B Optical system consists of a set of devices which are connected in a ring 
topology via a series of point to point links. Each of these links are physically independent. 



DVD Server 



Screen 4 : I Screen 1 



Screen 3 \ Screen 2 



Example High Speed D2B System 



Depending on its function, each Device in the system can: 

• supply, receive or pass-through source data (e.g. digital audio, video etc.). 

• send and receive control messages 

To support the sending and receiving control messages, each device has two unique addresses 

an application-related address and a ring-position related address. It is also possible to 

broadcast a control message to all devices or to a pre-selected group of devices. 

The protocols for control message communication are defined in the D2B Optical 

Specifications, 



HS D2B Performance 

At a frame rate of 48 kHz the High Speed D2B System offers a gross data rate of 36.864 
K4bps and a net source data rate of 34.56 Mbps (organised as ^.2 source bytes per High Speed 
D2B Frame). 

High Speed D2B Frame Structure 

The frame and sub- frame structures for High speed D2B are shown in Figures 1 and 2 
respectively. 



Block 0 f 4 8 fra m e s 




ImS @ 48kHz 



Fig 1 : High Speed D2B Frame Structure 

t 

The High Speed frame consists of two identical sub-frames, to provide 
some compatibility with the earlier CONAN system as in Proposal II, but 
this is not essential. The frame rate is proposed to be fixed at 48 
kHz. Synchronous channels requiring a lower rate (e.g. CD audio, 
MPEG 1) can be padded and ■ buf fe red accordingly within the synchronous 
data channels . 



First Subframc 




384 bits 



Source Data Field (46 Bytes) 
" i 1 



Transparent 
Channels 

Second Subframe 



10.42 ^iS @ 48kHz 





384 bits 



Source Data Field (46)Bytes 
1 1 



1 0.42 j.iS @ 48 kHz 
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In other embodiments, the number of bits in the frame and hence the 
number of bytes in the source data field may be different. 



Error Protection 

> 

The HS frame is protected by 2 parity bits, 1 in each subframe. 



r 



Source Data Transport 

Whenever source data (e.g. digital audio or video) needs to be transported over HS D2B, a 
source data connection must be established. This is called connection set-up. During the set- 
up, the required number of source data channels (bytes) are allocated from free channels 
within the HS D2B. For example, to carry a stereo audio signal from a CD player requires an 
allocation of 4 bytes. Source Data Connection protocols based on control messages are used 
for setting-up and removing connections. * 

For synchronous connections, this capacity remains allocated until the connection is removed. 

Synchronous connections have no superimposed framing or packet structure , altiiough applications 
are free to provide structure as desired. 

For asynchronous connections, the connection set-up establishes the starting allocation. 
However this allocation can be varied during the lifetime of the connection as described in the 
section on Asynchronous Connection Blocks. 

When all the capacity has been allocated, attempts to build further connections will fail- 
When this happens, the controlling AVC must decide which existing connection(s) 
(synchronous or asynchronous) need to be removed to release enough capacity for the new 
connection. The complexity of the allocation is hidden from the controlling AVC since each 
device is responsible for managing the allocation in its own output link (ring segment). 

Allocation of Source Data Capacity 

The source data field comprises the source data fields of the two sub-frames (with 46 + 46 
bytes capacity), flexibly partitioned into variable size sections as shown in the diagram. 

The first part is allocated to variable-rate asynchronous transport: whilst the synchronous (or 
fixed-rate asynchronous) source data capacity is allocated starting from the end of the frame. 

* Source data routing is similar to that of the CONAN IC, but 

10 with a larger number of bytes per frame, and hence a far 

greater number of switching permutations. Connection building 
can be performed for example by protocols based on the 
disclosure of EP-A-0360338 (PHN 12678) and EP-A-0432316 
(PHN 13189), adapted according to the ring topology protocols 
15 for this purpose are established using the control message 

frames to carry pre-arranged connection request instructions. 



Souraa Data Field Structure 



Left Subframe 



Right Subframe 



Preamble! Source Data 



iContro! ; 
}8c Status' 



. Preamble 



Source Data 



jContro! ! 
\8c Status^ 



ACBl 



I ACBn I i FrB 



see 



1 . ACBl. .ACBn are Asynchronous data Connection Blocks 

2. FrB represents free capacity for asynch (or sync) conns. 

3. SCB represents the synchronous data connection block 



A bytes (variable) 
92 - (A+S) bytes 
S bytes (variable) 



Asynchronous Connection Blocks (ACB) 

Asynchronous connection blocks are the means by which multiple variable-rate source data 
connections can be carried on HS D2B. They are the containers for asynchronous connections 
within the HS frame, carrying the packet switched data. Since more than one ACB may be 
present in the same frame allowing multiple simultaneous asynchronous connections. 

The ACB is segmented over a block of 48 HS frames (aligned to the block of 48 frames used 
for transporting control message frames, see figure 1). Note that the ACB header appears only 
in the first frame of the block of HS frames. The size of the ACB is: ACB width * 48 bytes. 
Thus by varying the width of the ACB from block to block, the capacity occupied by an 
asynclironous connection can be varied, subject to the limit of the total capacity of the frame. 

Asynchronous Connection Block (ACB) 



HS Frame 1 



. ACB 
ACBl 



HS 

Blaak 



HS Frame 2 ACBl 



HS Frame 48 ACBl 



ACBnl [ _ FrB 
ACBnj [FrB 



SCB 

; SCB 



ACBn! 



FrB j : SCB 



Example Application • ' ' 

The system shown on the first page consisting of a DVD server sourcing 4 different video 
signals could make use of the following source data field structure. The bit rate allocation 
may be varied for each connection as described in the section on Asynchronous Connection 
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Blocks. Note that since the destinations for the video signals are distributed around the 
system, not all asynchronous connections need to be present in all links in the system. For 
example, the asynchronous connection carry the video signal to Screen 1 (video 1 ) needs only 
to be present in the link from the DVD server to Screen 1. Each of the asynchronous 
connections could have a starting width of 24 bytes (per frame) and then could be varied 
individually as required for the variable rate video signal. 

Source FseSd Data A!locat:on for Multiple Video Sources 

Asynchronous Connections 

SCB ' 



HS Frame Source Data Field (92 bytes] 

Error Protection 

The contents of the Asynchronous Data Connection Blocks rely on protection within packets. 
Each Asynchronous Connection Block (ACB) is structured as follows; 

Asynchronous Connection Block (ACB) - 

! ACB Header ACB Data 



AWT 



ACB-Header 

ACB ID 6 bits 

Start of Packet flag 1 bit 

Reserved 1 bit 

ACB width 7 bits 

Reserved 1 bit 



Notes 

1. The ACB ID enables a receiving device to identify the connection whose data is carried by 
this block. 



2. The Start of Packet flag indicates whether the first data byte 
of this ACB is also the first byte of a packet (flag set to 
1) or whether it is a continuation of a packet. This allows 
for longer packets than the type detailed below, for example, 

3. The Reserved fields is for future extensions. 

4. The ACB width field indicates the number of (consecutive) 
bytes allocated to this asynchronous connection within each 
frame, encoded such that 1 means 2 bytes, 2 means 3 bytes etc. 
The minimum width of two bytes ensures space for .;the header 
in the first frame of the block. The ACB width may be 
restricted to ensure an integral number of packets within a 
block, where packet and/or frame sizes vary from these 
examples . 
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Within the capacity provided by the ACBs, source data is carried in the form of packets. The 
packet format is described in the following section. 

The ACB header format and its field si2es can be different according 
to the application. 

Free Capacity (FrB) 

The free capacity is held within an Asynchronous Connection Block 
(ACB) with ID = 0. This allows the hardware to identify the 
synchronous connection blocks easily. 

Synchronous Connection Block 

This block van be used to cairy both synchronous signals e.g, 16 bit PCM audio at 48 kHz or 
asynchronous signals whose bit-rate is fixed. Changes to the contents and size of this block 
can only be made by setting up a new connection or removing an old connection. These 
operations are defined in the source data connection protocols [1 ]. 



Packet Structure 

Asynchronous Data earned within either asynchronous or synchronous connections is 
formatted into packets whose structure is described below. This provides framing to allow a 
device receiving the data to identify the data and recover it correctly. Since each packet has its 
own ID, it is possible to interleave different streams of data over the same connection. For 
example a particular connection might carry predominantly packets containing video data 
interleaved with an occasional packet for control purposes. 



Packet Format 

I Jacket Head'^rl; 



Data 



Packet Header 

Packet Type 2 bits (the remainder of the packet definition applies for type 0) 

Packet ID 3 bits 

Reserved I bit 

Flow Control 1 bit 

Start of Pack. ' . 1 bit ■ \ .; 

Remaining Packets 8 bits * ' : ? • .. 

Number of bytes used; 8 bits , ^ 



Packet Data 

Data 
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42 bytes 



Error Protection 

Checksum/CRC 1 byte 

Notes on Packet Header 

1- Packet Type identifies the format of the packet, for example 
longer packets may be provided for bulk data transfer, as 
opposed to real-time channels. 

2. Packet ID identifies the type of data contained in the packet, 

such as audio/video/general data, to assist routing in the 
destination device. Packet ID "7"H is reserved for control 
(e.g. connection management) messages, with low latency 
compared with the existing control message channel (CF bits). 

3. Flow Control is used by a receiver of the data to indicate that its Rx buffer is full (when this Hag is set to I) 
When this IS detected by the source of the data, it wiU nornially suspend transmission. 

4. Remaining Packets indicates the number of packets remaining within the current pack (group of packets) 

5. Number of Bytes used indicates the number of bytes in tliis packet containing valid data 



Flow Control - - - _ _ . . . . _ . 

The flow control mechanism implemented via the flag in the packet header, requires there to 
be a connection from the destination device back to the source device. This connection, which 
would be built as part of the connection set-up of the signal whose flow is being controlled 
can have a much reduced capacity (mmimum I byte per frame) compared with e.g. the video 
signal to which it refers. It may for example have the same ACB ID " 
and use the Packet Header format. A single byte channel Could als^ 
be allocated as an SCB. 

Alignment of a packet within an Asynchronous Connection Block 

The start of the packet is indicated by the Start of Packet bit in the ACB header. When this bit 
is set, the first byte of data follo wing the ACB header is also the first byte of a packet. When 
this bit is not set, it indicates that the contents of the ACB are a continuation of a previous 
packet. 

Segmentation of the Packet 

The number of HS frames required for transmission of a packet is a function of the size of the 
packet and the width of its containing ACB in each HS Frame, If the ACB is n bytes wide 
then the packet will encompass (packet_size + size of ACB Header)/ ^ hs fiBmes 
Diagram showing how packets are loaded into an ACB 

The diagram below showing how an ACB of width 6 bytes is loaded with packets (of size 46 
bytes). This ACB holds six packets of which the first two are shown (A and B). Note that the 
ACB header occupies the first two bytes and that between each packet are 2 reserved bytes 
wnich are used as pa^Jing. Each ACB occupies the next available 
group of bytes,, according to the specified width of each channel 
If a connection becomes wider or narrower at the next ACB. the ACB 
for other connections are shifted up or down accordingly 
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1^ Packets carried in an Asynchronous Connection Block (ACB) 



Fr. 1 
Fr. 2 



ACBn 
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pA6 j 



pAl 
pA7 



I pA2 
i PA8 



pA3 
pA9 



pA4 
pAlO 



Fr. 8 



Fr..9 



pA41 



Fr. 10 PB5 



pA42 i 



Res. 



pB6 



pA43 I 
PBI I 
PB7 i 



pA44 ! 



pA45 
pB3 
pB9 



pA46 
pB4 
pBlO 



Frl6;rPB41 i ^ pB42 I PB43 | LpB41j [P^^^ \ ' P^"^^ 



Key 

Fr. Frame 

ACB_H ACB Header 

Res Reserved 

I PAl Packet A, first byte 



Packet Buffers 

Each HS D2B device which needs to send or receive asynchronous data will . require buffers 
for packets which have been received or are to be sent. The size of these buffers will be 
defined accojxling to requiransntzs. 
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1 . Introduction 
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^.1 Overview 

The Conan technology is a leap forward in the development of Connnriunication and Information networks for 
automotive consumer electronics products. It combines Source Data (digital audio, video or any other high- 
volume, real-time digital data) and Control Data, with the advantages of the Plastic Optical Fibre medium 
. (i.e. high data capacity and immunity to interference and noise). 

To achieve effective network design and facilitate product implementation, the 0CC8001 Optical Transceiver 
('Conan') provides maximum functional integration, including source data routing, communication 
management and all communication protocol tasks. 

Conan supports network protocol standards such as D2B Optical, and is fully compatible with systems buiit on 
a D2B Optical network. 



Head-Uriit ■ > 





Power 
Amplifier 



CU- 



Changer 





Navigation 
System 



Telephone 



Example System with o Ring Topology 



The data throughput on a Conan network is impressive. At a sampling rate/j of 44.1 kHz, it offers: 



Source Data 

Control Data 

4 Transparent Channels 



4.2 Mbps (equivalent to 3 x 16-bit stereo audio channels). 
Up to 176.4 kbps (918 control frames per sec). 
Up to 88.2 kbps each. 
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1.2 Features 

Conan has been optimised for implementation in 
benefits: 

Features 

Integration of Source 6t Control Data 
Multiple Source Data Channels 
Multiple Source Data Ports 
Multiple Source Data Formats 
SPDiF Audio Port 

I2C- and SPI-compatible Control Ports 
Flexible Source Data Routing 
Transparent Channels 

Programmable Clock Manager 

i 

Flexible Synchronisation 
Low Jitter PLL 

Fail-safe mechanism (Electrical Bypass) 

Network Position Identification 
Versatile Control Messaging 

Automotive Temperature Range 



consumer electronics products, and offers these features and 

f 

Benefits 

Reduces the number of components required for 
signal distribution and control 

Allows simultaneous bi-directional transmission 
of multiple source data channels 

Only one Conan needed per product, even with 
several interna! sources or destinations. 

Adaptability to a variety of components which 
support different digital data formats 

Provides easy integration with existing digital 
audio products 

Easy interface to wide range of microprocessors 

Versatile use of the network capacity 

Easy implementation of p^oprietar^^' control 
niessaging 

Easy integration in different products 

Network clock may be derived from a variety of 
sources 

Low jitter ensures high audio quality (i.e. low 
THD and low noise) 

In case of device failure, network operation can 
be maintained 

Each device can get its position on the ring 

Different addressing methods (incL broadcast) 
make best use of control channel capacity 

-40°C to +85°C (contact CaC for wider ranges) 
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1.3 Applications 

Conan has been specifically designed for easy implementation and integration of networked audio, video and 
j^mmunication products. Conan is optimised for use with (but not limited to) a ring topology, based on 
plastic optical fibre, for automotive applications, though can be equally well employed on other media (e.g. 
copper) and for other application areas. 

Products at nodes on the network can be sources or destinations for source data (or both, or neither), for 
example. CD-Changer (source), Amplifier (destination), Radio/Head-Unit (source and destination). 

A product can generate source data for transport on the network, and/or retrieve source data from the 
network. It can additionally send or receive control messages. Conan may be incorporated into a product as 
shown below. 
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A Conor) Device on the Network 

To achieve the highest possible efficiency, the network timing is synchronised to a System Master. The 
System Master is a product on the network which is able to generate the timing for the entire network. Only 
one Master device may be active on the network at any time. All other devices are Slaves. The Slaves get 
their timing from the Master by recovering the clock from the bit-stream received from the network. Conan 
can be configured by software as either a Master or a Slave. Up to 24 nodes may be present on the network. 
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1.4 Block Diagram 
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/CS SPIN SPOUT SCL 
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For I2C: j 
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Conon Block Diogrom 

Conan contains a Network Transceiver (Rx and Tx) to interface to the network. The network receiver recovers 
the clock and decodes the incoming bit-stream. The network transmitter encodes the outgoing data and 
transmits it on the network. Conan can be configured by software as either a Master or a Slave node on the 
network. 



Conan provides flexible access to up to 12 source data bytes within one frame (e.g. configured as three 16-bit 
stereo channels) on the network. The three source data input ports (SRO, 1 H 2] and three source data output 
ports (SXO. 1 Et 2) can transfer 8, 16, 24 or 32 bit source data into/out of the Conan through the Source Data 
Input and Source Data Output registers. 

The Router provides an easy and flexible way of controlling the routing of source data. All source data bytes, 
. coming either from the network receiver or from the source data input ports can be re-arranged, mixed and 

re-directed to the network transmitter or the source data output ports. Conan can also support SPDIF (also known 
'• as AES/EBU or IEC-958). Conan can even be used to route source data locally, from I.C. to I.C, within a product. 



O 
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In Slave mode. Conan's timing is derived from the incoming bit-stream. The network receiver recovers a clock 
from the incoming bit-stream using a low jitter, clock multiplying, phase locked loop (PLL). The PLL will lock 
t^ncoming bit-streams with sample rates of 30 to BOkHz. On loss of lock, the PLL is pulled to its lowest 
ffllquency (to minimise EMI). 

In Master mode. Conan's timing may be derived from a crystal, a source data clock applied to SCK or an SPDIF 
channel applied to SRO. The Oscillator circuitry allows a crystal to be connected directly to XTI/XTO. or some 
other clock source to be used. The PLL multiplies-up this timing source. The RX pin is over-sampled by a 
high-frequency clock and data is recovered by a digital state machine. 

An Electrical Bypass between RX and TX pins allows a node to be bypassed electrically. This bypass is 
automatically activated on power-up or reset as a safety feature. It helps to reduce the network start-up 
time, and can also be used as a fail-safe to isolate the node in case of loss of lock or other product failure 
(typically triggered by a watch-dog function). 

The Control Unit provides the interface from Conan to a microprocessor. It provides an 12C- or SPl- 
compatible interface, interrupt and error outputs, and transparent channel input/output. Conan is a slave on 
12C/SP1, so transfers must always be initiated by an external master. 

Internal registers are used to buffer the source data and control messages. It also contains the Routing 
Information Table (RIT) and control and status registers. These registers are accessible for reading or writing 
through the 12C/SPi interface. 
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1.5 Package Pin-Out and Pin Descriptions 



SCL 


1 


28 


SDIN Of ADO 


SDOUT or SDA 


2 


27 


ERROR 


/INT 


3 


26 


SER_OUT 


RX 


4 


25 


SERJN 


TX 


5 


24 


/CS or ADl 


RMCK- 


6 


23 


/RST 


VDDD 


7 


22 


VDOA 


GNDD 


8 


21 




SXO 


9 


20 


FILT 


SXl 


10 


19 


VREF 


SX2 


11 


18 


XTO 


FSY 


12 


17 


XTI 


SCK 


13 


16 


SR2 


SRO 


14 


15 


SRI 



Pin 


No. 


1/0 


Function 


Pin 


No 


I/O 


Function 


SCL 


1 


!n 


t2C a SP! clock 


SDIN or 
ADO 


28 


In 


SPI data in or I2C address select 


SDOUT 
or SDA 


2 


Out 


SP! data out or i2C data 


ERROR 


27 


Out 


Error indicator 


/INT ■ 


3 


Out 


Interrupt output (open drain) 


SER_ 
OUT - 


26 


Out 


Transparent channel out 


RX 


4 


In 


Network receive 


SER_ 
IN 


25 


In 


Transparent channel in 

i 


TX 


5 


Out 


Network transmit 


ICS or 
ADl 


24 


In 


SPI chip select or I2C address select 


RMCK 


6 


Out 


Received master clock 


/RST 


23 


In 


Reset {active low) 


VDDD 


7 




Power rail 


VDDA 


22 




Power rail 


GNDD 


8 




Ground 


GNDA 


21 




Ground 


SXO 


9 


Out 


Source data output port 0 


FILT 


20 




Loop filter 


SXl 


10 


Out 


Source data output port 1 


VREF 


19 


In 


PLL voltage (and reset timing) 


SX2 


11 


Out 


Source data output port 2 


XTO 


IC 


Out 


Crystal out 


FSY 


12 


I/O 


Frame sync. 


XTI 


17 


In 


Crystal in 


SCK 


13 


I/O 


Shift clock 


SR2 


16 


In 


Source data input port 2 


SRO 


14 


In 


Source data input port 0 


SRI 


15 


In 


Source data input port 1 



Pin Descriptions 

All pins are CMOS TTL logic level, except power, grounij, FILT, VREF. XTI and XTO. 
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2. Functional Description 

Data Transport 

The source data and control messages are transported on the network from node-to-node in frames 
generated by the System Master. Frames arc circulated at the same rate as the system sampling frequency, 
typically /s =44.1kHz. Frames are grouped into blocks of 48 frames. 

The frame is divided into two sub-frames Cleff and Vighf). At J, =44.1kHz, there will be 88,200 sub-frames 
per second. The left sub-frame is always the first of the pair transmitted on the network. At the physical 
level, bits are transported with bi-phasc encoding. The relationship between the block, frame, sub-frame and 
control frame is shown below. 




Block, Frame, Sub- frame and Control Frame Relationship 



2.1.1 Conan Sub-Frame 

Each sub-frame contains 64 bits, handled within Conan as 8 byte fields. The fields comprise the preamble, 
the transparent channels, 6 bytes of source data, and 8 control/status bits which make up the control frames 
and the SPDIF status bits. The sub-frame is shown below. 
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Preamble ' 

The preamble synchronises the network receiver. There are three types of preamble, identical to those defined 
in the IEC958 specification. They contain bi-phase coding violations v^/hich the receiver can recognise. The 
three unique preambles identify left, right and block sub-frames. The left preamble identifies the beginning 
a frame and the block preamble identifies the beginning of a block. The block preamble replaces every 48th * 
left preamble. This provides a block structure to which the control frame data is synchronised. 

Transparent Channels 

The four TC bits enable the transport of four serial channels for proprietan/ control or status information on the 
network, with no additional hardware or software overhead. The use of these channels is left open to System 
Integrators, who must define their own protocols for applications. Typical applications include the transport of 
raw control or status information, such as RS232-type data, VICS data. GSM data. PIN Card data, etc. 

Source Data Bytes 

The source data bytes carry the high-volume real-time digital source data. The twelve bytes per frame may 
be allocated flexibly, so that the devices in a system may use the source data bytes in the most efficient way 
for that system. The mechanism used for allocating the bytes is described in section 2.4. Source Data 
Routing. 

Status Bits 

If an SPDIF channel is being transported, the V. U and C bits contain the validity, user and channel status bits 
of the SPDIF channel. The left/right convention of these bits is determined by the left/right preambles of the 
Conan sub-frame. 

The Start Block bit SB identifies the block boundary of a synchronous SPDIF channel and is set after every 
block of 192 frames (synchronised with the SPDIF signal that is being transported). This synchronisation is 
performed automatically by the chip. The Parity bit P generates even parity for the entire sub-frame. 

Control Bits 

The control bits CFO a 1 carry the control messages (for controlling devices and sending status information). 
There are 2 CF bits per sub-frame, and a control frame is 192 bits long, therefore 96 sub-frames (48 left + 48 
right) are required to build-up a complete control frame. The control frame is described in the next section. 
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2.1.2 Control Frame 

The control frame is assembled from and aligned with a block of 96 sub-frames, i.e. the first two bits of a 
^w control frame are taken from the sub-frame with a block preamble, and subsequent pairs of bits are 
taken from subsequent sub-frames to build up a control frame. 
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Control Frame 

The fields of the control frame are: 

• Arbitration bits : 

These indicate if the control frame is free or occupied. Conan handles these bits automatically. 

• Destination Address 

This is the 12-bit device address of the destination of the message, in the range 'OOO'H to 'FFPH. The 
sending device writes this into its message transmit buffer for transmission. Certain addresses and address 
ranges have special meanings (see section 2.6). 

• Source Address 

This is the 12-bit device address of the sender of the message, in the range 'OOO'H to 'FFF'H. The 
receiving device can read this from its message receive buffer after reception. Certain addresses and 
address ranges have special meanings (see section 2.6). 

• Message Type and Length 

Two 4-bit fields normally used to indicate the type/length of the message. These bits are transported 
transparently by Conan. 

• Data 0 to 15 

The message data. All 16 bytes are always transported. The Message Length normally indicates how 
many of the 16 bytes are actually valid for the message. The sending device writes this into its 
message transmit buffer for transmission. The receiving device can read this from its message receive 
buffer after reception. 

• CRC 

A 16-bit Cyclic Redundancy Check value used to verify that the control frame has been transported 
without error. The CRC is generated by Conan automatically on message transmission and checked by 
Conan automatically on message reception. 

• ACK/NAK 

Acknowledge and Not Acknowledge (2-bits each) indicate successful message transmission. The use • 
of separate ACK and NAK flags allow reliable point-to-point onrf broadcast message transport. The 
flags are automatically filled by the destination device(s) (if present) and read by the sending device. 

• Reserved : 10 bits reserved. 
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2.2 Source Data Ports and Formats 



To maximise the application versatility of the chip, six source data ports are provided. This means that a 
product which needs to process source data for more than one interna! source or destination can do so withj^ 
only one Conan. These source data ports can transfer 8. 16. 24 or 32 bit source data, left or right adjusted, in 
to and out of the device. 

The source data ports provide access to the source data in the network bit-stream. Data can be input 
through three serial inputs (SRO. 1 h 2) and output through three serial outputs (SXO, 1 8t 2), All six ports 
use a common frame synchronisation FSY and a serial bit clock SCK. FSY and SCK may be set as either inputs 
or outputs, depending on the external hardware. If they are configured as inputs, then the data source(s) 
must be clocked by RMCK to be synchronised in frequency to the network bit-stream (although not 
necessarily in phase). 

With the control bits in the Source Data Port Control register, a variety of source data formats can be 
selected. Some common formats are shown in the following diagram: 
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Some Common Source Data Formats 

The register settings for these modes are given in section 4.1.4. 

The way that source data presented to the input ports is routed to the outgoing bit-stream, and the way the 
incoming bit-stream is routed to the output ports is determined by the source data routing, is explained later. 
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2.3 Source Data Port Synchronisation 

In a Conan network, the timing of all slave nodes is synchronised to one System Master. A slave node (e.g. a 
IfeD-Changer. Amplifier) must synchronise itself to the network by recovering the clock from the received 
'bit-stream. The synchronisation of the source data between the i.Cs and Conan inside a product is achieved 
using the SCK, FSY and RMCK signals. 

SCK is the 'bit clock- (also known as 'shift clock') for the source data. FSY is the 'frame synchronisation' 
which indicates 'left' or 'right' data. Conan's SCK and FSY pins can be configured as either inputs or outputs 
with the 1/0 bit in the Source Data Port Control register. 

RMCK is the clock recovered from the network ('Received Master Clock'). The RMCK pin is an output only. 
The RMCK output frequency is always a (known) multiple of the sampling frequency (e.g. 384/;). set in the 
Clock Manager Control register. 

2.3.1 Synchronisation in a Slave 

A slave node can act as a source or destination (or both or neither) for source data. In a source node, the 
outgoing source data must be synchronised to the network. This means that the I.Cs in the source node 
which generate the source data (e.g. a CD decoder chip) must be locked to the incoming network clock in 
frequency (but not necessarily in phase). In a destination node, the I.Cs which process the source data (e.g. 
D/A converter) must be locked to the incoming network clock in the same way. 

2.3.1.1 Source Example 1 (CD-Changcr) 

Here ? CD-Decoder is clocked by RMCK from Conan. The CD-Decoder gives Data to Conan in synchronism^ 
with RMCK. SCK and FSY could be either outputs from the l.C (as shown) or inputs, depending on what the 
I.e. supports. 
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CD-Decoder clocked by RMCK 



2.3. 1.2 Source Example 2 (CD-Changer) 

Here the CD-Decoder gives the Data to Conan in synchronism with SCK. RMCK is not used.- In this 
configuration. SCK and FSY must be inputs to the l.C (as shown), so that the CD-Decoder can synchronise to SCK. 
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2.3. 1.3 Destination Example (Amplifier) 

Here the D/A converter is clocked by RMCK from Conan. The D/A converter gets Data from Conan in 
synchronism with RMCK. SCK and FSY could be either inputs to the I.C (as shown) or outputs, depending on 
what the I.C. supports. 



To rest of 
product 



. CLK 

; DBt?t. ':^.: 

Destination 
■ LC. e^g. '^S^' 

D/A - T 
converter 



RMCK 



— 


SCK 


— 






FSY 


Data 



RMCK 
SCK 
FSY 
SXO 



Conan 
(slave) 



J 



D/A Converter clocked by RMCK 
2.3.2 Synchronisation in the System Master 

The System Master generates the timing for the whole network. A System Master can act as a source or 
destination (or both or neither) for source data. For a source or destination node (or both) the I.Cs which 
process the source data must be clocked by RMCK derived either from a crystal or an external master clock. 



2.3.2. 1 Example (Rodio/Heod-Unit) 

Here the CODEC is clocked by RMCK from Conan. The CODEC gives/gets Data to/from Conan in synchronism 
with RMCK. SCK and FSY could be either outputs from the I.C (as shown) or inputs, depending on what the 
I.C. supports. 
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2.4 Source Data Routing 



The Router provides an easy and flexible way of controlling the routing of source data. All source data bytes, 
^coming either from the receiver or from the input ports can be re-arranged, mixed and re-directed to the 
transmitter or the source data output ports. All source data inputs are double-buffered to allow 
re-synchronisation. The following figure shows the source data inputs and outputs of the chip, with the 
router in-between. 
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Source Do to Router 

An incoming (serial) sub-frame is shifted into Conan bit-by-bit into a shift register, copied into a source data 
input buffer, moved by the router into a source data output buffer, and finally shifted out from Conan 
bit-by-bit into the outgoing sub-frame. These shifting and moving operations delay the source data in the 
bit-stream as it passes through the node by a time equal to 4 Conan sub-frame times (approx. 45nS at 
J=A4AkHz): Nodes which do not modify the source data in the bit-stream (i.e. which are not sources of 
source data, e.g. Amplifiers) can reduce this delay to only 1 bit by activating. Conan's source data bypass (SBY 
bit in the Transceiver Control Register). 

The smallest amount of source data that Conan can manipulate individually is eight bits - a 'source data 
byte* (Dn). There are a total of forty source data bytes as possible inputs to the Router (sixteen from the 
■frame received from the network, and eight from each of the three source data input ports) numbered 
sequentially from OOH to 27H. The destinations for these input source data bytes are the forty output source 
data bytes (similarly numbered) of the transmit frame and the three source data output ports. The router is 
controlled by the Routing Information Table (BIT), which has forty entries. To route the input source data 
byte Dn with the index X to the output source data byte with RIT address offset Y, simply write the value X 
into the address offset Y of the RIT, * ' . ;■; 
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The example above shows a 16-bit stereo channel being routed from SRO'to the outgoing Conan bit-stream. 
In this case, the RIT offsets 1H. 2H. 9H ft AH must contain 10H. IIH, 14H a 15H respectively. All other bytes 
^the incoming frame are routed directly out to the outgoing frame unchanged. 

Source bytes with index OH a 7H for the left sub-frame (and 8H a FH for the right sub-frame) contain the 
transparent channels, control and status bits, so would normally always be routed through unchanged. 

After power-up or reset, the offsets OOH to 27H contain the values OOH to 27H respectively. All source data 
bytes received from the network are then routed directly out to the transmitter unchanged. 

The description above for the source data routing applies where there are 64 clock cycles per frame. Conan 
can also be configured for 48 clock cycles per frame (with the Source Data Port Control Register), and then 
the following diagram applies. 
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2.5 SPDIF Mode 

Conan can support SPDIF (also known as AES/EBU or IEC-958) with its SPDIF mode. The features of this mode 
1^ are: 

• An SPDIF channel from a local SPDIF source may be presented to SRO. 

0 An SPDIF channel generated at one node may be transported transparently (without loss) on the 
network to all other nodes (up to 24 source data bits and the VUC bits). 

• An SPDIF output is available from SXO to present to a local SPDIF destination, even if there is no SPDIF 
channel being transported on the network (see *SPDIF output from non-SPDIF data', section 2.5.3). 

SPDIF mode is activated when the SPD bit in the Source Data Port Control register is set. Input SRO and 
output SXO will then receive and transmit source data in SPDIF format. The other source data ports (SRI. SR2. 
SXl, SX2) remain available to communicate non-SPDIF data, as configured in the Source Data Port Control 
register. 

FSY and SCK must be synchronised to the SPDIF input, so they are automatically configured as outputs to 
maintain synchronisation requirements. Note that FSY and SCK are common for all source data ports. 
When Conan is in master mode, it can recover a clock from the SPDIF input on SRO. which it can then use 
internally (see Clock Management section 2.7). 

The SPDIF receiver on SRO checks for parity and bi-phase coding errors in the incoming SPDIF channel. If an 
error is detected, the validity bit (V) is automatically set. so that an SPDIF destination could be muted. The 
SPDIF transmitter on SXO generates the proper parity. 

The channel status bits and transmitter block timing are controlled by Conan. The transmitter simply encodes 
data written to Source Data Port 0. When outputting an SPDIF channel recovered from the network, the 
channel status, user and validity information is contained in the data. When outputting an SPDIF channel 
recovered from non-SPDIF data, 'fake' channel status, user and validity bits may be read from the SPDIF Data 
Register. ' 

In the SPDIF format, data is transported least-significant bit first. Conan's SPDIF ports take this into account 
and automatically change the order within the bytes to MSB first. However, the user has to ensure that the 
bytes are routed in the correct order through the RIT (see later). Both 16- and 24- bit SPDIF formats can be 
supported. 

2.5.1 SPDIF Input and Transmission 

If an SPDIF channel is input on SRO for transmission on the network, the RIT must be programmed so that 
source data bytes of the SPDIF input are routed correctly into the outgoing Conan sub-frame, and that the 
VUC bits are inserted into byte 7 of the sub-frame. 

For example, to transmit a 16-bit SPDIF channel on the network in the first two bytes of the Conan sub-frame, 
the RIT offsets IH, 2H a 7H for the left sub-frame could contain 12H. IIH a 13H respectively. Likewise for 
the right sub-frame, the RIT offsets 9H. AH a FH could contain 16H. 15H a 17H (see example below). 
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2.5.2 Reception and SPDIF Output 

If an SPDIF output i'"^ required from SXO, the RIT must be programmed so that source data bytes in the 
incoming Conan sub-frame are routed correctly to the SPDIF output, and that the VUG bits are taken from 
byte 7 of the sub-frame. 

For example, to receive a 16-bit SPDIF channel which is occupying the first two bytes of the Conan sub- 
frame, the RIT offsets 11H/i2H 8t 13H for the left sub-frame should contain 2H, IH a 7H. respectively. 
Likewise for the right sub-frame, the RIT offsets 15H. 16H H 17H should contain AH, 9H et FH. 

2.5-3 SPDIF Output from non-SPDIF data 

If an SPDIF output is required from SXO, even though there is no SPDIF channel being carried on the network, 
'fake' VUC bits can be inserted into the SPDIF output channel. The SPDIF Data Register (2CH) must be 
initialised with the desired VUC values (see section 4.1.3) and the contents of RIT offset 17H (which contains 
the preamble for the next left sub-frame) must be set to 28H, which then routes the fake VUC values into byte 
3 of SXO. The contents of the SPDIF Data Register are processed by Conan and are made available in offset 
28H for routing. ' 

When this is done, each SPDIF sub-frame output from SXO will have the VUC bits set as m the SPDIF Data 
Register. The bits in the register can be updated as fast as the control port will allow [ud to approx. 300 times 
per second). Typically, this feature will be used to control the V bit to mute/demute an SPDIF destination. 
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2.6 Control Message Transceiver 

The Control Message Transceiver is able to send and receive control messages to/from other devices on the 
network. It has a number of registers and message buffers associated with it - the Transmit Buffer (TxBuff). 
Receive Buffer (RxBuff), Message Control register. Message Status register. Device Address register. Groupcast 
Address register and Node Position register. These are shown below. 
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Control Message Transceiver Block Diagram 
2.6.1 Address Initialisation 

Following reset, Conan's device address is TFF'H. and it is able to send and receive messages. The device would 
normally then initialise its other addres5(es). 

Each node actually has five addresses:- its 'device address', used for point-to-point messaging; its 'broadcast 
address' (fixed at '3C8'H] to receive broadcast messages: its groupcast address' to receive groupcast messages; 
its 'node position* to receive messages address by node position; and its 'set-position address' (fixed at 'FOO'H) 
to receive the set-position command. These are all described in more detail later. 

The device address and groupcast address must be initialised by the local application software. The node 
position address is initialised as part of the network start-up procedure. 

Z6. h 1 Initialising the Device Address 

There are two ways to initialise the device address: 

• Using the automatic device address initialisation and verification mechanism built-into Conan 

• Initialising and verifying the device address manually 

Automatic Device Address Initialisation And Verification Mechanism 

Write the new device address as the destination address field into TxBuff then set the SA! ('Start Address 
Initialisation*) bit in the Message Control register (see section 4.1.6). Conan will check that the given address is 
unique on the network (by attempting to send a message to it), and if so. will write the verified address into its 
Device Address register (see section 4.1.12). The application may write a message into the data field of TxBuff 
before setting SAI, if needed. 

Once the address is tested, the MTX ('Message Transmitted') bit will be set in Message Status register (see 
section 4.1.7) and an interrupt may occur depending on the Int Mode (see section 4.1.9). The TXR 
(Transmission Result') bit reflects the result of the test and if set means that the address is unique in the ;V 
system and is now the adopted address for this device. 



Conan Optical Transceiver 



5^ 

If TXR ts not set. the address is rejected and the device address remains set to 'FFPH. Another device address 
may be tried by the application. Just as for any normal transmission, the RTI ('Reset Transmission Interrupt') 
bit must always be set ready for the next transmission. 

Manual Device Address initialisation And Verification # 

Simply write the new device address into Conan's Device Address register This mechanism should only be 
used in fixed/closed systems where address conflicts cannot occur, or for software test/development purposes. 

2.6. 1.2 Initialising the Groupcost Address 

To receive groupcasts. a device must write the least-significant byte of its groupcast address, value WH to 
'FF'H {except 'C8'H) into the Groupcast Address register(see section 4.1.10). 

2.6. 1.3 Initialising the Node Position 

This mechanism enables each device on the network to find out its position relative to the System .Master. 
The System Master application software initiates the procedure by sending the following message: 
Destination Address = 'FOO'H. Msg Type/Length - don't care. Data[0] = 03. 

This message is passed around the network from device to device within a single control frame. Each device 
receives the message, stores its position in its Node Position Address register (see section 4.1.8) and passes 
the message on to the next device. This is all done automatically by Conan - no application software is 
needed in slave devices. 

The procedure is complete when the message returns back to the System Master. At this moment, every 
device will know its position on the network, regardless of the transmission result. 
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2.6.2 Sending a Message 
2.6.2. 7 General Procedure 

The general procedure to send a message is to write the message into the transmission buffer (TxBuff) and 
then set the SIX ('Start Transmission ) bit in the Message Control register. The control message transceiver 
reformats the message for transmission and sends the message with up to 5 retries, 10ms apart, if necessary, 
A gap of 10ms is also inserted between outgoing messages to prevent a node monopolising the control 
channel. The diagram below shows how Conan formats a message for transmission into the control frame. 
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Message Transmission 

When the transmission is complete. MTX ('Message Transmitted') will be set and an interrupt may occur 
depending on Int Mode. TXR ('Transmission Result') is set if the transmission was successful and reset if the 
transmission failed. The condition must always be cleared by setting the RTl ('Reset Transmission Interrupt') bit 
in the Message Control register. A flow-chart for this sequence is given in section 3.2.4. 

Conan can send a message in four different ways: 

• point-to-point, to a device with a known address, 

• broadcast, to ail devices. 

• groupcast, to a group of devices (e.g. ail amplifiers), and 

• node position addressing, to a device at a certain position on the ring 
These different methods are described below. 

2,6,2,2 Point-to-Point 

To send a point-to-point message, write the device address of the destination into the destination address field 
of the Tx buffer, then initiate transmission as described in 'General Procedure' above. 

The receiving Conan will set the ACK bit if it receives the message correctly, otherwise it will set the NAK bit. 
The sending Conan examines the ACK et NAK bits and generates a transmission result available in TXR. 

2.6,23 Broadcasting 

Broadcasting allows a message to be sent to ail devices on the network. The broadcast address is '3C8'H. All 
nodes will receive messages broadcast to this address. This address is fixed within Conan so there is no software 
overhead involved in initialising the broadcast address. To send a broadcast message, write 'BCS'H into the 
destination address field of the Tx buffer, then initiate transmission as described in 'General Procedure' above. 
The receiving Conan(s) will set the ACK bit if they receive the message correctly, otherwise they will set the 
NAK bit. The sending Conan may retry up to 5 times. lOmS apart. If a destination has already received the 
message (i.e. its Rx buffer already contains the message) then it will not set the NAK bit. The transmission 
result is available in TXR. 
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Broadcast messages have an ID byte inserted by Cona'n automatically at the end of their data field, which is 
incremented for each new broadcast message (not on each (re)transmission). The ID enables receiving Conans ' 
to determine automatically whether the message is new, or if it is a re-transmission of a message which they 
have successfully received already. The ID occupies data byte 15. This means only 15 data bytes (0..14) are 
available for message data. ^11 

If a Conan is triggered to send a message while a broadcast transmission from another Conan is in progress, it 
will wait until the broadcast is complete before attempting to send the message. 

2.6.2A GroupcQsting 

Groupcasting allows broadcasting to a particular group of devices which have the same groupcast address 
only. Groupcast Addresses are in the range ■300'H to '3FF'H (excluding '3C8'H for normal broadcasts). To send 
a groupcast message, write the groupcast address into the destination address field of the Tx buffer, then 
initiate transmission as described in 'General Procedure' above. The transmission result is available in TXR. 
Groupcasting is the same as broadcasting in all other respects. 

2.6,2.5 Node Position Addressing 

To send a message to a node position, write the node position address (in the range '400'H to '4FPH, where 
the least-significant byte is the node position of the destination device) into the destination address field of 
the Tx buffer, then initiate transmission as described in 'General Procedure' above. The transmission result is 
available in TXR. 



Conan Optical Transceiver 



51 

" 2.6.3 Receiving a Message 

The diagram below illustrates how a received control frame is formatted by Conan for passing to the 
^ application. 
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Message Reception 

When a valid message is received. MRX is set in the Message Status register and an interrupt may occur 
depending on Int Mode. The condition should be cleared by writing a 1 to RRt ('Reset Receive Interrupt'). 
When the message has been read, the receiver buffer is re-enabled by setting RBE ("Receive Buffer Enable'). 
A flow-chart for this sequence is given in section 3.2.4. 
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2.7 Clock Management 

Conan can be configured by software as either a Master or a Slave. Conan needs a clock source to set the 
timing of its transmitter and to use internally. 

In Slave mode. Conan's timing is derived from the incoming bit-stream. The network receiver. recovers a clock ^ 
from the incoming bit-stream using a low jitter, clock multiplying, phase locked loop (PLL). The PLL will lock 
to incoming bit-streams with sample rates of 30 to 50kHz. On loss of lock, the PLL is pulled to its lowest 
frequency (to minimise EMI). 

In Master mode. Conan's timing may be derived from a crystal, SCK input or an SPDIF channel applied to SRC 
The Oscillator circuitry allows a crystal to be connected directly to XTI/XTO, or some other clock source to be 
used. The PLL multiplies-up this timing source. The RX pin is over-sampled by a fast clock and data is 
recovered by a digital state machine. 

The Clock Manager is controlled by the Clock Manager Control register and illustrated below. 
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Clock Manager Block Diagram 

The PLL is enabled automatically on power-up, but can be disabled (pulled to its lowest frequency) to reduce 
EMI. If no transitions are occurring on the RX pin, the PLL is automatically pulled to its lowest frequency. A 
programmable divider in the PLL allows the frequency of a connected crystal to be 256/,, 384/; or 512/. The 
RMCK output is a programmable clock output, offering a divided down version of the internal ]S3ef^ clock 
generated by the PLL A range of frequencies between 64/ and 1 536/ are possible. 

The PLL Mux selects one of four inputs for the PLL As a slave, orily the RX input may be used. As a master, 
there is a choice between the crystal oscillator (or other clock source applied to XTl). bit clock (from SCK input) 
and SPDIF data (from SRO input). If the crystal is not selected, the oscillator will be disabled to reduce EMI. 

The PLL lock state is made available to applications on the ERROR pin (pin 27), the ERR bit in the Transceiver 
Status Register and the POR/ERR bit in the Message Status Register. The time taken for the PLL to lock after 
receivmg valid frames (or change in sampling frequency) is typically less than lOmS. Lock is declared if three 
consecutive valid left preambles arc found. If two consecutive.left preambles are not valid, loss of lock is 
declared. ' ■ 
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2.8 Transparent Channels 

Conan can transport four channels of proprietary serial data on the network. The use of these channels is left 
open to System Integrators, who must define their own protocols for applications. Typical applications include 
0 the transport of raw control or status information, such as RS232-type data, VICS data, GSM data. etc. 

The 4 transparent channels are transported independently in the 4 TC bits in the Conan sub-frame. Conan 
provides access to one of the four channels at a time (selected with the TCO-1 bits in the Transceiver Control 
Register) although any number of devices may monitor the same transparent channel. It is not possible for a 
device to send and receive on different transparent channels. 

Data presented to the SER_IN pin of Conan in one device may be transported transparently to Conan in 
another device and output at its SER_OUT pin. The SER_1N pin is sampled twice every frame (i.e. 88.2 k- 
samples per sec atyj=44.1kHz), on both FSY edges. Data is valid for reading from the SER_OUT pin on both 
FSY edges. 

Asynchronous Transport 

RS232-type data, up to about 19.200 baud, can be transported asynchronously with no hardware or software 
overhead. Conan 1 over-samples the signal on its SER_IN pin, and inserts the bit sample into the selected TC 
bit in the Conan sub-frame. Conan 2 receives the sub-frame, reads the selected TC bit, and outputs it at its 
SER_OUT pin. The destination (e.g. UART) should over-sample the SER_OUT to recover the data. In both cases, 
the over-sampling helps to preserve the mark/space ratio of the original data. 
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Asynchronous Transport 

Of course, they may be more than just the one destination Conan shown above. Any number of Conans may 
monitor the same transparent channel. 

Synchronous Transport 

The data throughput may be increased up to a maximum of 88.2 kbps by using synchronous data, i.e. where 
the data is presented to the SER_IN pin in synchronism with the clock recovered from the network, and where 
the sample is taken when the bit to be sampled is known to be stable. In this case, additional hardware (a 
data synchroniser) will be needed. 

The data synchroniser must hold the data given to it from the microprocessor in a latch, and present it to 
SER_IN on the FSY edge (for timing diagrams, see section 4.5.2.1). 
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2,9 Reset 

Conan can be reset by hardware or software in 3 different ways: 

• Power-on reset: when power is applied to Conan, it resets itself automatically. 

• Hardware reset: the /RST input (pin 23) is an active-low. level-triggered TTL input. A microprocessor can 
reset Conan by pulling the pin low (<0.8V) for (at least) 2mS. then setting it high again. 

•. Software reset: by writing a 1 to the RES bit in the Message Control register 

Selection of I2C or SPI 

I2C or SPI is selected during a 'hard" reset (not a software reset). I2C mode is selected by holding SCL high 
durmg the reset. SPI mode is selected by holding SCL low during the reset. The selection is completed when 
the reset pm goes back high. The microprocessor must wait for the POR interrupt before starting to 
communicate on the selected I2C or SPI. 

After Reset 

Immediately following any of the above reset conditions, the ERR bit in the Transceiver Status Register is set 
Of the PLL has lost lock), the PGR/ERR bit in the Message Status register is set to indicate power-on an 
interrupt is raised which cannot be disabled (/INT goes low), and the Device Address is set to 'FFPH. The 
crystal oscillator is disabled on reset (see section 4.1.5). 

The POR interrupt must be cleared by setting the RPI bit in the Message Control register. This will clear the 
interrupt (/INT goes high) and clear the PGR/ERR bit. 

Revision Code 

A 1-byte revision code is provided, so that application software can distinguish between different versions of 
the Conan. 

It can be read by a microcontroller from Data 0 (register number OxAD) in TxBuff. It is only available for 
reading immediately after resetting the chip and before the first message is sent. 

For the Conan Engineering Samples, the revision byte was 0. For the Conan Production Devices, the revision 
byte IS 1. Future versions will have different values. 
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2.10 Error Handling _ „ 

Conan is able to detect errors and report them to the application, including: 

«0bi-phase coding or parity errors in the Conan sub-frame (from the network bit-stream) 

• loss of lock to the incoming bit-stream from the network 

• loss of lock to an incoming SPDIF channel on SRO 

Errors are signalled with the ERROR pin (pin 27). the ERR bit in the Transceiver Status Register and the 
POR/ERR bit in the Message Status Register (depending on Int Mode). Which of the above errors are actually 
reported is selected with the ME. MDL and MSL bits in the Transceiver Status Register 

The ERR and POR/ERR bits are latched. If an error condition sets them, they stay set until they are cleared. 
The'ERR bit is cleared by writing a zero to it. The POR/ERR bit is cleared by writing a 1 to the RPI bit in the 
Message Control register 

The ERROR pin is not latched. The pin goes high if an error condition occurs, and remains high for as long as 
the error condition exists. If a bi-phase coding or parity error occurs, the ERROR pin is high for the duration 
of the next sub-frame. If that sub-frame has no error. ERROR will go back low. 

2.11 Interrupt Handling 

The three events which can cause an interrupt are: 

• Error (highest pricrily) 

• Message transmission completed 

• Message received 

The /INT output from Conan is a HL level, active low. open drain output. When an event occurs, the /INT pin 
goes low. and stays low until the interrupt is cleared. The events that trigger an interrupt can be selected 
with the Interrupt Mode register (see section 4.1.9). The'modes are: 

• Interrupts disabled (except power-on reset) - must poll the registers instead . 

• Rx and Tx interrupts only enabled 

• Rx. Tx, and Error interrupts enabled 

• Error interrupt only enabled 

) Where the error interrupt is enabled, the error types can be masked using the bits in Transceiver Status 
Register (see section 4.1.2). A flow-chart is given in section 3.2,4. 

Rx and Tx interrupts are queued behind an Error interrupt. If an interrupt occurs due to an error and the Rx 
or Tx condition becomes true before the error interrupt has been cleared, then as soon as the Error interrupt is 
cleared another interrupt will follow to indicate the Rx or Tx condition. 

If an error occurs whilst a Tx or Rx interrupt is active, then the error flags are set (ERR in the Transceiver 
Status Register and POR/ERR in the Message Status Register) to inform the application. Interrupts will recur 
until the ERR bit is cleared. 
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The.d,3gram below shows which events, when enabled or disabled by bit masks, result in which outputs. 
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CLAIMS 



1. A local communication system comprising a ring 
network conveying source data in both variable rate and 
fixed rate channels, by means of a regular frame 
structure, each frame providing a fixed number of source 
data fields, wherein each fields can be reserved 
dynamically to form part of a fixed-rate channel using 
the same fields in each frame, and at other times can be 
allocated to form part of a variable rate channel for 
irregular data packets. 

2. A system according to claim 1, wherein blocks for 
fixed rate data are allocated starting from one end of 
the frame, while fields for variable rate data are 
allocated starting at the other end of the frame. 

3. A system according to claim 1 or 2, wherein 
successive frames are grouped into blocks, and each 
variable rate channel occupies the same fields through 
all frames of a block, fields being reallocated to 
provide variation of channel width only at- the start of 
each block, v 

4. A system according to claim 1, 2 or 3, wherein a 
block* header is transmitted to reserve a variable rate 
channel of a specified width for a plurality of 



successive frames. 
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5. A system according to claim 4, wherein said block 
header occupies one or more fields of the channel for at 

5 least the first frame of the block. 

6. A system according to claim 4 or 5, wherein at the 
start of a block, each channel's block header occupies 



10 



15 



20 



25 



one or more fields which can be located in the frame with 
reference to the widths of other channels. 

7. -A system according tb any preceding " claim', wherein 
each variable rate channel comprises a selection of 
fields fixed over a predetermined sized block of frames," 
the width of all such channels being specified in the 
source data fields of the first frame or frames of each 
block. 

8. A local communication system comprising a ring 
network conveying source data in both variable rate and 
fixed rate channels, by means of a regular frame 
structure in which certain portions of each frame are 
reserved for said fixed rate channels, whether or not 
said fixed rate channels are in use, and certain other 
portions of each frame are available for said variable 
rate channels, and a Irontrol mechanisiri is provided f or 
allocating said variable rate portion' dynamically between 



r 
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different channels . 



9. A system according to claim 1, 2 or 8, wherein the 
frame rate is synchronised with one or more digital audio 

5 data- sources, for which source data is carried in the 
fixed rate portions of each frame. 

10. A system according to claim 1, 2, 8 or 9 , wherein 
each frame conveys control bits forming part of a control 

10 message frame transmitted over plural frames. 

11. A local communication system comprising a 
synchronous ring network conveying source data in a fixed 
rate channel over one segment of the ring and while said 

15 fixed rate channel is multiplexed with variable rate 
channels over another segment of the ring. 

12. A system according to claim 11, wherein said 
multiplexed fixed rate channels and variable rate 

20 channels comprise different respective portions within 
a regular , frame structure on said other segment of the 
ring, 

13. A fibre optic local communication system, for 
25 example according to any of claims 1 to 12, suitable for 

in-vehicle entertainment, communication and/or navigation 
purposes, having an overall source data capacity greater 



than 10 Mbps, the fibre optic channel conveying 4B5B 
8B10B encoded data. 



14. A system according to any preceding claim, wherein 
variable data source data channels are mapped on to the 
network in asynchronous transfer mode packets. 

15. A fibre optic local communication system, for 
example according to any of claims 1 to 12, suitable for 
in-vehicle entertainment, communication and/or navigation 
purposes, having an overall source data capacity greater 
than 10 Mbps, the source data comprising" variable data 
rate audio and video data, carried by asynchronous 
transfer mode (ATM) packets. 

16. A system according to claim 15, wherein the headers 
and data fields of ATM packets do not necessarily consist 
of 5 bytes and 48 bytes respectively. 

17. A local communication system substantially as 
described herein. 



